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A BASIC interpreter is a useful tool for writing small programs in a quick and easy way. For the control of experiments, however, 
it lacks a number of essential features. A BASIC-hke command interpreter BACO has therefore been developed. It runs on PDP-11 
computers with the RSX-11M operating system. Its major advantages over BASIC are: (1) new FORTRAN routines can be 
implemented simply, and (2) interrupts can be processed at interpreter level. 

As an application the implementation is described of routines to control a CAMAC system and of a multichannel analyzer 
simulation. The CAMAC commands follow the line proposed by the ESONE committee. Since an interpreter is inherently rather 
slow, the commands are intended for moderately fast data transfer and interrupt handling, which suffices for the control of many 
experiments 


1. Introduction 

It is impossible to write one single program satisfy¬ 
ing the specific needs of the numerous types of nuclear 
physics experiments. On the other hand the different 
experiments have so many software requirements in 
common, that writing a separate program for every 
application easily leads to duplication of features in 
many dedicated programs. Therefore it is advantageous 
to have a program that carries out a number of the 
common tasks and that can be extended with all the 
dedicated routines required for a specific kind of experi¬ 
ment. 

One of the common tasks is the interpretation of 
commands, which suggests the use of a BASIC interpre¬ 
ter. Since BASIC, however, is more directed towards 
off-line programs, the experimental applications gave 
rise to the development of the new command interpreter 
BACO [1,2]. The interpreter is used as a basis for a 
number of programs, thereby assuring that the general 
commands are equally well recognized by all programs, 
and that differing commands anyhow have the same 
syntax. This is especially convenient for inexperienced 
computer users. 

BACO performs the following tasks: 

- it accepts and decodes the commands, which are of a 
simple BASIC-like format; several standard com¬ 
mands facilitate the control of the experiment, 

- it intercepts interrupts issued by the experiment and 
coordinates interrupt processing according to com¬ 
mands defined beforehand, 

- it enables easy implementation of FORTRAN 
routines for special applications. 


The BACO interpreter is used on the three PDP-11 
computers of our department. In nuclear physics large 
amounts of data are produced. For storage and pre¬ 
liminary analysis of these data, a minicomputer is very 
well suited, whereas further analysis is performed on a 
larger system. The off-line data analysis and program 
development is carried out on a PDP-11/70 computer, 
while two PDP-11/34A minicomputers are used for 
data acquisition and measurement control. The PDP- 
11/70 requires a multi-user operating system to deal 
with its more than 30 terminals. In order to provide 
maximum compatibility between the three computers, 
they are all run with the multi-user operating system 
RSX-11M V4.0. This has the important advantage that 
tasks developed and tested on the PDP-11/70 can be 
transported as taskfile to a PDP-11/34 and run im¬ 
mediately without any adaptation. In addition, RSX- 
11M has many features not available in smaller operat¬ 
ing systems. The main disadvantage is the space require¬ 
ment of the operating system (in our case about 32k 
words). The minicomputers thus need more memory 
than an operating system like RT11. To meet the re¬ 
quirements of all our present applications, the PDP- 
11/34’s are supplied with 124k words of memory (the 
maximum for these computers). For many applications, 
however, about half of this would be sufficient. 

At present BACO is extensively used in our depart¬ 
ment as the basis for three programs. The Spectrum 
Analysis Program SAP [3] is usually running at the 
PDP-11/70. The second, called SPECTR [4], runs at the 
PDP-11/34A computer used for experiment control at 
the 6 MV tandem Van de Graaff accelerator. SPECTR 
controls the event-mode data collection via a home-built 
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Fig. 1. The structure of the measuring program ANALYS. 


interface or via a CAMAC system. The same program is 
also used for the off-line sorting of event-mode data on 
the PDP-11/70 computer. The third program, 
ANALYS, is described in this paper as an example of 
BACO and the CAMAC interfacing. This on-line mea¬ 
suring program, in use at the 3 MV Van de Graaff 
accelerator, serves two purposes: 

- it provides a programmable multichannel analyzer 
(hence its name), 


- it supplies an advanced set of CAMAC commands 
for control of the measurement by setting and read¬ 
out of parameters, via two CAMAC crates. 

These two tasks are performed via a set of 
subroutines. They constitute two branches connected to 
the BACO basis and via the Operating System to the 
corresponding hardware. The interaction is schemati¬ 
cally indicated in fig. 1. 
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2. Properties of the BACO command interpreter 

An experiment is controlled by commands typed in 
on the terminal, like “CLEAR 1” to clear spectrum 
number 1. BACO interprets these commands, evaluates 
the arguments if present (in the above example the 
argument is the spectrum number) and transfers them 
to the appropriate routine that performs the task: in this 
case the array containing the specified spectrum is set to 
zero’s. 

The commands can be executed immediately after 
being typed in, but they can also be loaded to constitute 
a “control program” for later execution. The syntax of 
such a program very much resembles that of the lan¬ 
guage BASIC, from which the name BACO is deduced: 
BAsic COmmand interpreter. 

A control program may contain commands to 
evaluate arguments for a routine or also to determine 
whether a call to the routine is in fact required. The 
following example gives an impression of such a pro¬ 
gram: 

#10 LET SPEC = 0 

#20 IF (CONTENT(SPECl)> 10000) THEN LET 
SPEC = 1 

#30 IF (CONTENT(SPEC2)> 10000) THEN LET 
SPEC = 2 

#40 IF (SPEC > 0) THEN CLEAR SPEC 
The example shows four command lines preceded by 
line numbers, which serve to determine the order in 
which the commands will be executed. With the aid of 
BASIC-like commands (“LET”, “IF”) and of dedicated 
routines (the function “CONTENT”), a parameter is 
evaluated (“SPEC”) which serves as argument for 
another dedicated routine (“CLEAR”). 

During the measurement the computer will collect 
data for a preset time, or until the experiment itself 
generates a so-called interrupt, e.g. triggered by the 
collection of a preset amount of beam charge on the 
target. As a consequence of the interrupt a previously 
declared part of the control program (a subroutine) is 
executed in order to read out the data, to store the 
results on disk or magnetic tape, and to reset and restart 
the measurement. 

The properties of BACO relevant to its application 
in on-line control programs are summarized as follows: 

1. BACO contains most BASIC features. 

2. Commands and syntax are easily learned and han¬ 
dled, as in BASIC. 

3. Contrary to BASIC, implementation of new dedi¬ 
cated FORTRAN routines and variables is easy. 

4. A running control program can be interrupted by the 
experimentalist, e.g. for checks or for corrections. 
The program then continues where it was inter¬ 
rupted; it is thus not required to start from the very 
beginning. 

5. The program can delay itself for a specified time, or 


until the occurrence of an interrupt. 

6. A set of commands (a subroutine) can be specified 
that will be executed after an interrupt. 

These properties are elaborated in the following sec¬ 
tions. 

2.1. A versatile interpreter 

Most BASIC commands have a BACO equivalent, 
albeit that the syntax is slightly different. Examples are 
the statements LET, IF..., FOR... NEXT, GOTO, 
CALL, RUN, etc. Much attention is paid to the input 
from and output to terminal and file. The PRINT 
statement e.g. will often be used to show results or 
parameter settings. These can easily be listed in table 
form with the aid of FORMAT specifiers. Texts, num¬ 
bers, or even expressions can be read in with the IN¬ 
PUT statement. 

Commands and control programs can also be fetched 
from file at the moment they are needed. This gives a 
limited overlay capability and thus enables large control 
programs. 

2.2. An easy syntax 

Experimentalists usually prefer short and easy com¬ 
mands over syntactical perfection. Although an inter¬ 
preter can check a BASIC statement, like LET Ll% = 
L% 4- LEN(T$), faster for type conflicts etc., the BACO 
equivalent LET LTOT = L 4- LENGTH(TEXT) is sim¬ 
pler to read, and thus reduces the risk of typing errors. 
BACO variables are identified by names consisting of 
up to six alphanumerical characters, and the type of a 
variable is determined by the type of the value assigned 
to it. Thus the type of the variable R, resulting from the 
expression 

# LET R — X + Y 

is “number” if X and Y are numbers, and is “string” if 
X and Y are strings (the addition operation between 
strings is defined as concatenation). 

2.3. Easy implementation of new FORTRAN routines 

When a new routine is implemented, the interpreter 
has to recognize the corresponding command. After the 
addition of a new FORTRAN routine named CLEAR 
(which clears a spectrum) with the integer argument I 
(denoting the number of the spectrum to be cleared), 
BACO should translate the command 

# CLEAR I 

to the FORTRAN subroutine call 
CALL CLEAR(I) 

The link between the command and the FORTRAN 
routine is made via a file that is accessed when the 
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BACO interpreter task is built. The name of the com¬ 
mand and the type of its arguments are defined by the 
addition of a single line: 

FORTRAN CLEAR INTEGER 

The line states that BACO should recognize the com¬ 
mand “CLEAR” by which the FORTRAN subroutine 
with the same name is called and that it has an argu¬ 
ment of the type “INTEGER”. 

With respect to the implementation of FORTRAN 
functions BACO has the following characteristics differ¬ 
ing from those of many BASIC interpreters: 

- A command referring to a user implemented sub¬ 
routine has the same syntax as a standard BACO 
command. Whereas the BASIC call reads: 

500 CALL “CLEAR” (I) 
the BACO equivalent is: 

#500 CLEAR I 

without the additional word “CALL”, and without 
quotes or parentheses. It has the same syntactical 
structure as a reference to a standard BACO routine 
like PRINT in e.g. 

#510 PRINT I 

- The arguments can be “called-by-value” as well as 
“called-by-name”. The first method is used when the 
subroutine needs the value of an argument, while the 
latter case enables the subroutine to return a value, 
calculated within the subroutine. 

- A function can be implemented in the same way as a 
subroutine. The result of a function can only be a 
number or a logical, as FORTRAN does not allow 
other types. 

- It can be useful to make some variables accessible by 
both the FORTRAN routine and by the BACO user. 
Therefore variables in a FORTRAN common parti¬ 
tion can be defined to be recognized also as BACO 
variables. 

2.4. Interruption of a running program via the terminal 

A program in BACO consists of a set of statements 
each preceded by a line number. Normally the program 
lines are executed sequentially, and the BACO interpre¬ 
ter will only accept a new command after completion of 
the program. A faulting program could thus be stopped 
only by the complete abortion of the interpreter task via 
an MCR command. This could result in loss of data and 
improperly closed files. To avoid this, a running BACO 
program can be interrupted with the MCR command 

> INT 

which activates the small task “INT” that directs BACO 
to suspend the execution of the control program and to 
accept commands from the experimentalist. 

After the intervention BACO will continue with the 
statement where the interruption occurred. 


2.5. The delay option 

After the command 
# WAIT (sec) 

the BACO task will delay the execution for (sec) sec¬ 
onds. After that it resumes with the next statement. This 
command is useful in a control program to enable a 
measuring device to collect data. In the case of the 
multichannel analyzer simulation described below, the 
command is used to stop BACO during the (DMI) 
accumulation of a spectrum, as this does not require any 
software intervention. 

It should be mentioned that the execution can also 
be restarted by an interrupt, so that the statement can 
be used to wait for such an interrupt. 

2.6. Interrupt handling 

An interrupt can occur at an arbitrary moment, and 
it requires the immediate execution of a set of com¬ 
mands. The user can specify a routine which contains 
these commands. When an interrupt occurs, first the 
current line of the running control program is finished. 
Then the program is temporarily stopped and the speci¬ 
fied routine is executed. After that, execution of the 
main program resumes at the point where it was inter¬ 
rupted (see also section 4.2.3). 


3. The analyzer simulation 

The BACO interpreter described above constitutes 
the framework for the implementation of application 
oriented routines. The ANALYS version thus simulates 
a programmable multichannel analyzer with all the usual 
analyzer features. For the interfacing of the ADCs to 
the computer, several concepts are generally followed, 
often involving the use of more or less intelligent 
CAMAC modules [5,6]. We have chosen for a direct 
coupling to the computer via two kinds of home built 
interfaces. One is developed for event mode data collec¬ 
tion and is used by the program SPECTR [4]. The other 
interface is applied with the accumulation of singles 
spectra and is controlled by the program ANALYS. The 
last interface consists of the following components: 

- A fast Direct-Memory-Increment interface to link up 
to eight 8192-channel ADCs to the computer, which 
can handle a total count rate of up to 120000 per 
second. 

- A video screen, which displays a (part of the) spec¬ 
trum selected by the experimentalist. 

- A number of additional keys to change the displayed 
part of the spectrum and the ROI (Region-Of-Inter- 

est). 

All three hardware parts have their own software driver. 
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so that programs can communicate with them in a 

standard RSX-11M manner (see fig. 1). 

The analyzer simulation contains the following fea¬ 
tures: 

- As many spectra can be defined as will fit in the 
available memory of the computer. Each channel has 
a maximum content of 2 24 — 1 counts. 

- Commands are available to display (part of) a spec¬ 
trum, to clear a spectrum, and to change or read the 
content of a channel. 

- The lower and the upper limits of the displayed part 
can be read out by the interpreter, which enables the 
user to program any number of ROIs. 

- Spectra can be dumped on and restored from tape. 


4. Implementation of CAMAC features 

As BACO is developed as an interpreter for measure¬ 
ment control, it forms a excellent framework for exten¬ 
sion with CAMAC routines. The obvious problem 
inherent to CAMAC control via an interpreter is its 
slowness. To circumvent this problem one can decide to 
control CAMAC via a high level language like FOR¬ 
TRAN and develop a set of routines to facilitate this 
[7,8]. This, however, forces the user to write control 
programs in FORTRAN, while it is much easier and 
faster to program a BASIC-like interpreter, especially 
for people unexperienced with computers. Our aim 
therefore was minimalization of the slowness by an 
intelligent home-written CAMAC driver [9] which can 
act fast on the basis of presetted commands. For 
ANALYS however, this is of little importance because 
only slow processes like presetting and reading out of 
counters and the positioning of the detector, are allotted 
to CAMAC. 

4.1. Hardware and system-end of the software 

Our CAMAC systems contain the Nuclear Enter¬ 
prise 9030 controller, which is coupled to the PDP 11 
Unibus in one computer via the NE interface, and in 
the two others via a home-built serial interface based on 
a BB11H with opto-couplers. As programs communi¬ 
cate with CAMAC via the driver, the use of other 
controllers requires only adaption of this driver and no 
changes in the BACO task itself (see fig. 1). The driver 
concept has the following additional advantages: 

- The CAMAC driver follows the line of other RSX- 
11M devices. Communication with it thus proceeds 
via the standard QIO calls and other EXECUTIVE 
features, either as assembler macro’s or as FOR¬ 
TRAN subroutine calls. Consequently the communi¬ 
cation with CAMAC is much more transparent for 
the FORTRAN programmer. 

- A CAMAC crate can be accessed simultaneously by 


more than one task, and even by more than one user, 
with the possibility of linking specific LAMs (Look- 
At-Me interrupts) to specific tasks. 

4.2. Syntax of the CAMAC commands 

For the format of the CAMAC commands the 
recommendation for a CAMAC extension to a BASIC 
interpreter [10] is taken as a guideline, although some 
differences are induced by the existing BACO syntax. 

The most important CAMAC commands are demon¬ 
strated in the following example (a presettable counter). 

4.2.1. Declaring a module 

Before a CAMAC module can be accessed, it should 
be declared with the command: 

#DECLARE<name)CAMAC((A>(N)<C» 

«Fr)(Fw»«Cr»«Cw»((GL» 

Here (name) is the formal name to be used from now 
on in commands referring to the module. The symbols 
(A), (N) and (C) stand for the subaddress, station 
number and crate number, respectively, where the mod¬ 
ule can be found, while (Fr) and (Fw) indicate the 
read- and write-access functions. The parameters (Cr) 
and (Cw) are one or more data conversion snecifiers 
for read and write, respectively. (Cr) is specified if the 
data of the CAMAC modules are coded in, e.g., one’s 
complemented or binary-coded-decimal format. In these 
cases (Cr) should be “COM” or “BCD”, respectively, 
which results in automatic decoding upon a read refer¬ 
ence to the module. (Cw) is used correspondingly for a 
module expecting input in coded format. The parameter 
(GL) is the (graded) LAM number associated with an 
interrupt from the specified module (normally its station 
number). If a default value suffices, the corresponding 
parameter can be omitted. 

If one wishes to use the formal name SCALER to 
refer to a counter located at station 4 and subaddress 1, 
which produces data in binary-coded-decimal format, 
and uses default settings for the remaining parameters, 
the declaration would be: 

#100 DECLARE SCALER CAMAC (1 4)( )(BCD) 

4.2.2. Referring to a module 

A module can be accessed by simply using its formal 
name in an expression, just like the name of any other 
variable. The content of the counter can thus be read 

by: 

#150 PRINT “counter content is:”, 

SCALER/1000, “kCounts” 

and preset by the normal BACO assign statement: 
#200 LET SCALER = 1000 

Some operations require a reference to a module 
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already declared with a different subaddress or a differ¬ 
ent function. This is possible, but it will not be discussed 
here for the sake of brevity. 

Actions without data transfer are carried out with 
the CONTROL command: 

# CONTROL(name) (control-function) 

Here (control-function) is the standard CAMAC func¬ 
tion code F(n) for the control action. For most CAMAC 
functions BACO has already a symbolic name, For 
example, clearing the counter can be done by: 

#250 CONTROL SCALER CLEAR1 
4.2.3, Interrupts 

The counter in the present example is assumed to 
send a LAM signal to the computer after receiving a 
preset number of pulses. This interrupt should cause the 
execution of a certain subroutine. The LAM and the 
subroutine are connected by the statement 

# ON (name)(line-number) 

The number (line-number) points to the first line of the 
subroutine. In the current example this could be: 

#300 ON SCALER #350 

The subroutine beginning with statement #350 could 
be used to clear the LAM: 

#350 CONTROL SCALER CLRLAM 
#360 RETURN 

To summarize the example, the consequences of an 
interrupt issued by the counter are: 

- the current commandline is finished, 

- the commands beginning at line #350 are processed, 

- after the RETURN statement (at line #360), execu¬ 
tion of the main program is resumed with the com¬ 
mand line following the one that was interrupted. 

5. Conclusion 

The command interpreter BACO runs with the RSX- 
11M multi-user system and is especially designed for 
use in physics experiments. The interpreter resembles 
BASIC with respect to the syntax and the available 
commands. The commands thus are simple, and further 
simplification results from an adjustment of the BASIC 
syntax which improves readability. 


BACO supplies a framework that has to be completed 
with dedicated FORTRAN routines to match the appli¬ 
cations. The available facilities make it very easy to 
implement those routines. The combination of a set of 
routines simulating a multichannel analyzer is described 
as an example. 

An experiment frequently demands program action 
via an interrupt. The user can define a routine that 
starts up when the interrupt occurs. This feature and the 
structure of BACO itself make it very well suited for the 
implementation of a set of CAMAC routines applicable 
for moderately fast experiment control functions. 

More details of BACO are described in the extensive 
manual [11], which is available on request. 

This work was performed as part of the research pro¬ 
gram of the “Stichting voor Fundamenteel Onderzoek 
der Materie” (FOM) with financial support from the 
“Nederlandse Organisatie voor Zuiver-Wetenschappe- 
lijk Onderzoek” (ZWO). 
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